home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1590.txt < prev    next >
Text File  |  1994-08-01  |  13KB  |  396 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          J. Postel
  8. Request for Comments: 1590                                           ISI
  9. Updates: 1521                                                 March 1994
  10. Category: Informational
  11.  
  12.  
  13.                    Media Type Registration Procedure
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  This memo
  18.    does not specify an Internet standard of any kind.  Distribution of
  19.    this memo is unlimited.
  20.  
  21. Abstract
  22.  
  23.    Several protocols allow the use of data representing different
  24.    "media" such as text, images, audio, and video, and within such media
  25.    different encoding styles, such as (in video) jpeg, gif, ief, and
  26.    tiff.  The Multimedia Internet Message Extensions (MIME) protocol [1]
  27.    defined several initial types of multimedia data objects, and a
  28.    procedure for registering additional types with the Internet Assigned
  29.    Numbers Authority (IANA).  Several questions have been raised about
  30.    the requirements and administrative procedure for registering MIME
  31.    content-type and subtypes, and the use of these Media Types for other
  32.    applications.  This document addresses these issues and specifies a
  33.    procedure for the registration of new Media Types (content-
  34.    type/subtypes).  It also generalizes the scope of use of these Media
  35.    Types to make it appropriate to use the same registrations and
  36.    specifications with other applications.
  37.  
  38. 1. Introduction
  39.  
  40.    RFC 1521 [1] defines a procedure for the registration of new data
  41.    types for use with the Multimedia Internet Message Extensions (MIME).
  42.    This registration mechanism was designed to make the identifiers for
  43.    a given data type available for use and to prevent naming conflicts.
  44.    With the growth of new multi-media protocols and access mechanisms,
  45.    this process has the promise of forming a unified general
  46.    registration service for Internet Protocols.  These types, previously
  47.    called "MIME Types", are now called "Media Types".
  48.  
  49.    The registration process for Media Types (content-type/subtypes) was
  50.    initially defined in the context of the asynchronous mail
  51.    environments.  In this mail environment, there is a need to limit the
  52.    number of possible Media Types to increase the likelihood of
  53.    interoperability when the capabilities of the remote mail system are
  54.    not known.  As Media Types are used in new environments, where the
  55.  
  56.  
  57.  
  58. IANA                                                            [Page 1]
  59.  
  60. RFC 1590           Media Type Registration Procedure          March 1994
  61.  
  62.  
  63.    proliferation of Media Types is not a hindrance to interoperability,
  64.    the original procedure is excessively restrictive and needs to be
  65.    generalized.
  66.  
  67.    This document addresses the specific questions raised and provides an
  68.    administrative procedure for the registration of Media Types.  This
  69.    procedure also address the registration requirements needed for the
  70.    mapping of Object Identifiers (OIDs) for X.400 MHS use to Media
  71.    Types.
  72.  
  73. 2. Media Type Registration Procedure
  74.  
  75.    The following procedure has been implemented by the IANA for review
  76.    and approval of new Media Types.  This is not a formal standards
  77.    process, but rather an administrative procedure intended to allow
  78.    community comment and sanity checking without excessive time delay.
  79.  
  80. 2.1 Present the Request for Registration to the Community
  81.  
  82.    Send a proposed Media Type (content-type/subtype) to the "ietf-
  83.    types@cs.utk.edu" mailing list.  This mailing list has been
  84.    established for the sole purpose of reviewing proposed Media Types.
  85.    Proposed content-types are not formally registered and must use the
  86.    "x-" notation for the subtype name.
  87.  
  88.    The intent of the public posting is to solicit comments and feedback
  89.    on the choice of content-type/subtype name, the unambiguity of the
  90.    references with respect to versions and external profiling
  91.    information, the choice of which OIDs to use, and a review of the
  92.    security considerations section.  It should be noted that the
  93.    proposed Media Type does not need to make sense for every possible
  94.    application.  If the Media Type is intended for a limited or specific
  95.    use, this should be noted in the submission.
  96.  
  97. 2.2 Submit the Content Type to the IANA for Registration
  98.  
  99.    After two weeks, submit the proposed Media Type to the IANA for
  100.    registration.  The request and supporting documentation should be
  101.    sent to "iana@isi.edu".  Provided a reasonable review period has
  102.    elapsed, the IANA will register the Media Type, assign an OID under
  103.    the IANA branch, and make the Media Type registration available to
  104.    the community.
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. IANA                                                            [Page 2]
  115.  
  116. RFC 1590           Media Type Registration Procedure          March 1994
  117.  
  118.  
  119.    The Media Type registrations will be posted in the anonymous FTP
  120.    directory "ftp.isi.edu:in-notes/media-types" and the Media Type will
  121.    be listed in the periodically issued "Assigned Numbers" RFC [2].  The
  122.    Media Type description may be published as an Informational RFC by
  123.    sending it to "rfc-editor@isi.edu" (please follow the instructions to
  124.    RFC authors [3]).
  125.  
  126. 3. Clarifications On Specific Issues
  127.  
  128. 3.1 MIME Requirements for a Limited Number of Content-Types
  129.  
  130.    Issue:  In the asynchronous mail environment, where information on
  131.    the capabilities of the remote mail agent is not available to the
  132.    sender, maximum interoperability is attained by restricting the
  133.    number of content-types used to those "common" content-types expected
  134.    to be widely implemented.  This was asserted as a reason to limit the
  135.    number of possible content-types and resulted in a registration
  136.    process with a significant hurdle and delay for those registering
  137.    content-types.
  138.  
  139.    Comment:  The need for "common" content-types formats does not
  140.    require limiting the registration of new content-types.  This
  141.    restriction may, in fact, hinder interoperability by causing separate
  142.    registration authorities for specific applications which may register
  143.    values in conflict with or otherwise incompatible with each other.
  144.    If a limited set of content-types recommended for a particular
  145.    application, that should be asserted by a separate applicability
  146.    statement specific for the application and/or environment.
  147.  
  148. 3.2 Requirements for a Published Specification
  149.  
  150.    Issue:  Content-Type registration requires an RFC specifying the data
  151.    format or a reference to a published specification of the data
  152.    stream.  This requirement may be overly restrictive for the use of
  153.    content-type registration for file attachments and distribution
  154.    because a public specification may not be available for a number of
  155.    widely used and exchanged objects.
  156.  
  157.    Comment:  MIME required the documentation of a specific content-type
  158.    to allow the unambiguous identification of a defined type.  This
  159.    intent is met by the identification of a particular software package
  160.    and version when registering the content-type and is allowed for
  161.    registration.  The appropriateness of using a Media Type with an
  162.    unavailable specification should not be an issue in the registration.
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. IANA                                                            [Page 3]
  171.  
  172. RFC 1590           Media Type Registration Procedure          March 1994
  173.  
  174.  
  175. 3.3 Identification of Security Considerations
  176.  
  177.    Issue:  The registration process requires the identification of any
  178.    known security problems with the content-type.
  179.  
  180.    Comment:  It is not required that the content-type be secure or that
  181.    it be free from risks, but that the known risks be identified.
  182.    Publication of a content-type does not require an exhaustive security
  183.    review, and the security considerations section is subject to
  184.    continuing evaluation.  Additional security considerations should be
  185.    periodically published in an RFC by IANA.
  186.  
  187. 3.4. Recommendations and Standards Status
  188.  
  189.    Issue:  The registration of a data type does not imply endorsement,
  190.    approval, or recommendation by IANA or IETF or even certification
  191.    that the specification is adequate.
  192.  
  193.    Comment: To become Internet Standards, protocol, data objects, or
  194.    whatever must go through the IETF standards process.  This is too
  195.    difficult and to lengthly a process for the convenient and practical
  196.    need to register Media Types.  It is expected that applicability
  197.    statements for particular applications will be published from time to
  198.    time that recommend implementation of, and support for, data types
  199.    that have proven particularly useful in those contexts.
  200.  
  201. 4. Security Considerations
  202.  
  203.    This memo does not address specific security issues but outlines a
  204.    security review process for Media Types.
  205.  
  206. 5. Acknowledgements
  207.  
  208.    Most of the words in this RFC were written by other people --
  209.    primarily John Klensin and Greg Vaudreuil -- and my contribution has
  210.    been to slightly modify some sentences, delete some phrases, and to
  211.    rearrange some paragraphs.  This means that i am responsible for all
  212.    the bad ideas and mangled English, and they deserve the credit (and
  213.    rightly) all the good ideas.
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. IANA                                                            [Page 4]
  227.  
  228. RFC 1590           Media Type Registration Procedure          March 1994
  229.  
  230.  
  231. 6. Author's Address
  232.  
  233.    Jon Postel
  234.    USC/Information Sciences Institute
  235.    4676 Admiralty Way
  236.    Marina del Rey, CA  90292
  237.  
  238.    Phone: 310-822-1511
  239.    Fax:   310-823-6714
  240.    EMail: Postel@ISI.EDU
  241.  
  242. 7. References
  243.  
  244.    [1] Borenstein N., and N. Freed, "MIME (Multipurpose Internet Mail
  245.        Extensions) Part One:  Mechanisms for Specifying and Describing
  246.        the Format of Internet Message Bodies", RFC 1521, Bellcore,
  247.        Innosoft, September 1993.
  248.  
  249.    [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
  250.        USC/Information Sciences Institute, July 1992.
  251.  
  252.    [3] Postel,J., "Instructions to RFC Authors", RFC 1543,
  253.        USC/Information Sciences Institute, October 1993.
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. IANA                                                            [Page 5]
  283.  
  284. RFC 1590           Media Type Registration Procedure          March 1994
  285.  
  286.  
  287. Appendix A -- IANA Registration Procedures for Media Types
  288.  
  289.    MIME has been carefully designed to have extensible mechanisms, and
  290.    it is expected that the set of content-type/subtype pairs and their
  291.    associated parameters will grow significantly with time.  Several
  292.    other MIME fields, notably character set names, access-type
  293.    parameters for the message/external-body type, and possibly even
  294.    Content-Transfer-Encoding values, are likely to have new values
  295.    defined over time.
  296.  
  297.    In general, parameters in the content-type header field are used to
  298.    convey supplemental information for various content types, and their
  299.    use is defined when the content-type and subtype are defined.  New
  300.    parameters should not be defined as a way to introduce new
  301.    functionality.
  302.  
  303.    In order to ensure that the content-type and subtype (that is Media
  304.    Type) values are developed in an orderly, well-specified, and public
  305.    manner, MIME and other applications use the registration process for
  306.    Media Types defined in this RFC which uses the Internet Assigned
  307.    Numbers Authority (IANA) as a central registry for such values.
  308.  
  309.    In order to simplify and standardize this Media Type registration
  310.    process, this appendix gives templates for the registration of new
  311.    values with IANA.  Each of these is given in the form of an email
  312.    message template, to be filled in by the registering party.
  313.  
  314.    Registration of New Content-type/subtype Values:
  315.  
  316.    Note that MIME is generally expected to be extended by subtypes.  If
  317.    a new fundamental top-level type is needed, its specification must be
  318.    published as an RFC or submitted in a form suitable to become an RFC,
  319.    and be subject to the Internet standards process.
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. IANA                                                            [Page 6]
  339.  
  340. RFC 1590           Media Type Registration Procedure          March 1994
  341.  
  342.  
  343.       ==================================================================
  344.  
  345.       To:  IANA@isi.edu
  346.       Subject:  Registration of new Media Type content-type/subtype
  347.  
  348.       Media Type name:
  349.  
  350.       (If the above is not an existing top-level Media Type, please
  351.       explain why an existing type cannot be used.)
  352.  
  353.       Media subtype name:
  354.  
  355.       Required parameters:
  356.  
  357.       Optional parameters:
  358.  
  359.       Encoding considerations:
  360.  
  361.       Security considerations:
  362.  
  363.       Published specification:
  364.  
  365.       (The published specification must be an Internet RFC or RFC-to-be
  366.       if a new top-level type is being defined, and must be a publicly
  367.       available specification in any case.)
  368.  
  369.       Person & email address to contact for further information:
  370.  
  371.       ==================================================================
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. IANA                                                            [Page 7]
  395.  
  396.